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© A security mechanism is described for a distrib- 
uted data processing system. Each server in the 
system maintains a set of security ratings giving its 
view of the security levels within the system. When a 
first server wishes to initiate a connection with a 
second server, the two servers exchange security 
information, by means of messages, so as to estab- 
lish an overall security level for the connection, 
based on a combination of the security information 
maintained by both servers. However, if the first 
server decides that the second server cannot be 
trusted to discuss security, messages are ex- 
changed containing no security information, and 
each server establishes its own security level for the 
connection, based on its own locally held security 
information. . 
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DISTRIBUTED DATA PROCESSING SYSTEM 



Background to the invention 

This invention relates to distributed data pro- 
cessing systems. More specifically, the invention is 
concerned with a data processing system compris- 
ing a number of servers connected together by one 
or more interconnection routes. By a "server" is 
meant a unit that provides some service to the 
system; for example, a computer unit which pro- 
vides a data processing service or an electronic 
mail service. The interconnection routes may, for 
example, comprise a local area network (LAN) or a 
telephone link. 

The invention is particularly concerned with 
federated computer systems. A federated system 
is a distributed data processing system in which 
there is no central controller or data store. Each 
server is capable of operating autonomously, and 
there is no master unit for directing the operation of 
the system. 

in such a system, servers can exchange in- 
formation by setting up connections between them, 
by way of the interconnection routes. Each such 
connection between two servers is asymmetric, in 
that the server at one end starts the connection 
process. This server is referred to herein as the 
initiator, while the server at the other end is re- 
ferred to as the responder. 

In a federated system, one important consider- 
ation is that of security, i.e. of ensuring that only 
those with permission to access servers do so. In 
particular, when a connection is requested, some 
check has to be made concerning the validity of 
that connection. Thus, a check must be made as to 
whether the responder is sufficiently secure to 
meet the needs of the initiator, whether there is a 
suitable route between the two servers that will 
preserve the security of their conversations, and 
whether the responder is prepared to be used by 
the initiator. 

This problem of providing security is made 
more difficult by the completely distributed nature 
of the system, and by the fact that there is no 
single central authority to control the security of the 
system. 

The object of the present invention is to pro- 
vide a novel way of overcoming the problem of 
providing security in a federated system. 

Summary of the invention 

According to the invention there is provided a 
distributed data processing system comprising a 
plurality of servers wherein each server separately 



maintains security information relating to security 
levels in the system, and wherein, in operation, 
when a first server initiates a connection with a 
second server, these two servers exchange secu- 
5 rity information to establish an overall security level 
for the connection based on a combination of the 
security information maintained by both servers. 



10 Brief description of the drawings 

Figure 1 is a block diagram of a distributed data 
processing system. 

Figure 2 is a flow chart showing the operations 
is performed by an initiator in setting up a pro- 
posed connection. 

Figure 3 is a flow chart showing the operations 
performed by a responder in setting up a pro- 
posed connection. 

20 

Description of an embodiment of the invention 



One distributed data processing system in ac- 
cordance with the invention will now be described 
25 by way of example with reference to the accom- 
panying drawings. 



Overall view of the system 

30 

Referring to Figure 1 , the distributed data pro- 
cessing system comprises a plurality of servers 10, 
11, 12 interconnected by routes 13, 14. 

For example, the servers may comprise free- 

35 standing computers, each of which is capable of 
independent operation, as well as contributing a 
service to the system as a whole. The interconnec- 
tion routes may comprise local area networks 
(LANs) or telephone links. 

40 The system is organised as a federated sys- 

tem; that is, there is no central controller or store 
for controlling the operation of the system as a 
whole, instead, the responsibility for system control 
is shared among the individual servers. 

45 Security in the system is described by means 

of security levels which can be assigned to servers 
and to routes between servers. Because of the 
federated nature of the system, there is no single 
repository of information about security levels in 

so the system. Instead, each server maintains its own 
local view of the security levels in the system. This 
consists of a table containing a security rating for 
each server in the system, and for each intercon- 
nection route. It is important to note that the local 
views held in different servers may not be the 
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same; for example, different servers may give a 
particular route different security ratings. 



Security ratings 

Each security rating comprises a set of secu- 
rity factors, where each factor in turn comprises a 
set of values. For example, a security rating for a 
particular server might be: 

(COLOUR = (RED, BLUE, YELLOW), DAY = 
(MONDAY)) 

This consists of two factors COLOUR and DAY, 
where the factor COLOUR consists of three values 
RED, BLUE and YELLOW, while the factor DAY 
consists of just a single value MONDAY. 

In this example, this security rating indicates 
that the server is entitled to receive electronic 
documents with status codes RED, BLUE or YEL- 
LOW only, and only on Monday. 

A security factor that contains just a single 
value (such as the factor DAY above) is referred to 
herein as an exact factor, since it indicates that a 
particular condition must be matched exactly. Con- 
versely, a factor that consists of more than one 
value (such as the factor COLOUR in the above 
example) is referred to herein as an inexact factor, 
since it indicates that there is a degree of choice 
about this factor. Similarly, a security rating that 
contains only exact factors is referred to as an 
exact rating, while a rating that contains one or 
more inexact factors is referred to as an inexact 
rating. 



Default ratings 

The following rules are specified to cover de- 
fault conditions, where some or all of the informa- 
tion in a security rating is omitted. 

(i) If a security rating is omitted completely, it is 
assumed that this is equivalent to a rating com- 
prising all possible factors with all possible val- 
ues present. 

(ii) If a factor is omitted from a security rating, it 
is assumed that this is equivalent to the factor 
being present with all possible values. 

(iii) An empty factor (i.e. one with no values) is 
not allowed. However, it is possible to give a 
factor a special NULL value. 



Binding security ratings 

In operation of the system, different security 
ratings may be combined by a process referred to 
as binding. This consists of forming the logical 
intersection of the ratings, to produce a resultant 



rating consisting of values common to all these 
ratings. Where a particular factor is not present in 
one or more of the ratings, the above default rules 
apply. 

5 For example consider the two ratings: 

(DAY = (SAT, SUN, MON). COLOUR = (RED, 
BLUE)) 

(DAY = (MON, TUE)) 

The result of binding these two ratings will be: 
70 (DAY = (MON), COLOUR = (RED, BLUE)) 

It should be noted that, in this example, the 
factor COLOUR is not present in the second of the 
ratings, and it is therefore assumed as a default 
condition, that this factor is present with all possi- 
;s ble values. 



Initiating a connection 



20 Before any two servers can exchange informa- 

tion, a logical link, referred to herein as a connec- 
tion, must first be set up between them. The server 
that initiates the connection is referred to as the 
initiator and the other server is referred, to as the 
25 responder. 

As mentioned above, the security level of a 
server or route is not known in an absolute manner 
by a single authority. Rather, the security level 
ascribed to a particular connection depends on an 
30 interaction between the initiator and responder, tak- 
ing account of the locally held security ratings in 
each of them. 

The following list indicates the various security 
ratings that may influence the security .level of a 
35 particular proposed connection. 

R1: the initiator's rating of itself. 
R2: the initiator's rating of the responder. 
R3: the initiator's rating of the route or routes 
available to connect to the responder. 
40 R4: the responder's rating of itself. 

R5: the responder's rating of the initiator. 

R6: the responder's rating of the route chosen 

by the initiator. 

45 

Initiator 

Referring now to Figure 2. this shows the op- 
eration of the initiator in setting up a connection. 

so (2-1) The initiator specifies a required security 
level (RSL) for the connection. 
(2-2) The initiator then binds the level RSL with 
the ratings R1 and R2 to produce a resultant 
security rating LA2. If LA2 is empty, (i.e. there 

55 are non intersecting ratings in RSL, R1 and R2) 
then the attempted connection has failed, since 
it is not possible to satisfy the security require- 
ments of the initiator. 
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(2-3) The initiator now selects a route to the 
responder, and binds the security rating R3 of 
this chosen route with LA2 to produce a resul- 
tant security rating LA3. It it is not possible to 
find a route for which LA3 has non-empty rat- 
ings, the attempted connection fails. 
(2-4) The next action taken depends on whether 
the rating R2 (i.e. the initiator's view of the 
security rating of the responder) is exact or 
inexact. 

(2-5) If the rating R2 is exact (i.e. contains only 
exact factors as defined above), this means that 
the initiator does not trust the responder to 
discuss security. That is, the responder cannot 
be trusted to receive security information or to 
make decisions about security levels, and the 
initiator must take all responsibility for the secu- 
rity of the connection. 

In this case, therefore, the initiator sends a con- 
nection request message to the responder, con- 
taining no security information. 
(2-6) If, on the other hand, R2 is inexact (i.e. 
contains at least one inexact factor), this means 
that the initiator considers that the responder is 
capable of discussing security levels. The in- 
itiator therefore transmits a connection request 
message to the responder, containing all the 
factors of LA3 that correspond to inexact factors 
of R2. These factors represent the initiator's 
view of what the responder has to know about 
the required security level. Factors in LA3 which 
correspond to exact factors in R2 are not trans- 
mitted, since the initiator believes that the re- 
sponder is not capable of discussing these fac- 
tors. 

The net result is that the initiator sends only 
security information on which it believes the re- 
sponder can be trusted to behave correctly. If it 
does not trust the responder at all. it sends no 
security information to it. 



Responder 

Referring now to Figure 3, this shows the ac- 
tion of the responder when it receives a connection 
request message. 

(3-1) The action of the responder depends on 
whether any security information (LA3) is 
present in the connection request. 
(3-2) If security information is present, the re- 
sponder binds LA3 with R4. R5 and R6 to pro- 
duce a resultant security level LA6. If LA6 has 
any empty ratings, the attempted connection 
has failed. 

(3-3) If the attempted connection has not yet 
failed, it is now considered to have been suc- 
cessful. The responder returns a confirmation 



message to the initiator, informing it that the 
connection has been successfully completed, 
and informing it of the final security level LA6 for 
the connection for those ratings in LA3. The 
5 responder then adopts this level LA6 as its view 

of the overall security level SLA for this connec- 
tion. 

(3-4) If. on the other hand, there is no security 
information in the connection request, the re- 
10 sponder binds the available local security ratings 
R4, R5 and R6 to produce the security level 
LA6, and adopts this as its view of the overall 
security level SLA of the connection. As before, 
the responder returns a confirmation message to 
75 the initiator, but in this case, the message con- 
tains no security information. 
Referring again to Figure 2, the action of the 
initiator on receiving a confirmation message is as 
follows. 

20 (2-7) The initiator checks whether the confirma- 
tion message contains a security level with a 
subset of LA6's ratings. 

(2-8) If so, the initiator adopts this subset of LA6 
and the other ratings of LA3 as its view of the 
25 overall security level SLA of the connection. 

(2-9) Otherwise, the initiator uses LA3 as its 
view of the overall security level. 
In summary, it can be seen that where the 
initiator does not believe the responder to be ca- 
30 pable of discussing security, it does not transmit 
any security information to it. In this case, both the 
initiator and responder rely solely on their own 
local knowledge of the security levels in the system 
to decide whether or not the connection succeeds, 
35 and each produces its ov/n view of the overall 
security level for the connection. 

On the other hand, where the initiator believes 
that the responder is capable of discussing secu- 
rity, a dialogue takes place between them to estab- 
40 lish an agreed overall security level, based on the 
local views of both the initiator and the responder. 

It should be noted that in the described sys- 
tem, it is not necessary for the initiator and the 
responder to have a common security vocabulary; 
45 that is, one may consider security factors that the 
other is completely unaware of. This avoids the 
need to synchronise the security vocabulary of the 
servers, and avoids the need for unnecessary ex- 
changes of security information which could, in 
so itself, compromise security. 



Claims 

55 1 . A distributed data processing system comprising 
a plurality of servers wherein each server sepa- 
rately maintains security information relating to se- 
curity levels in the system, and wherein, in opera- 
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tion, when a first server initiates a connection with 
a second server, these two servers exchange secu- 
rity information to establish an overall security level 
for the connection based on a combination of the 
security information maintained by both servers. 5 

2. A system according to Claim 1 wherein, in 
operation, if the security information maintained by 
the first server indicates that the second server 
cannot be trusted to receive security information, 

the servers exchange messages containing no se- 10 
curity information and each server establishes its 
own security level for the connection based on its 
own locally held security information. 

3. A system according to claim 1 or 2 wherein said 
security information comprises a set of security rs 
ratings for each server in the system. 

4. A system according to claim 3 wherein each 
security rating comprises at least one security fac- 
tor comprising at least one value. 

5. A system according to claim 4, wherein the first 20 
server determines that the second server cannot be 
trusted to receive security information if the secu- 
rity rating of the second server, as viewed by the 

first server, contains only security factors with only 

one value. 25 
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© A security mechanism is described for a distrib- 
uted data processing system. Each server in the 
system maintains a set of security ratings giving its' 
view of the security levels within the system. When a 
first server wishes to initiate a connection with a 
second server, the two servers exchange security 
information, by means of messages, so as to estab- 
lish- an overall security level for the connection, 
based on a combination of the security information 
maintained by both servers. However, if the first 
server decides that the second server cannot be 
trusted to discuss security, messages are ex- 
changed containing no security information, and 
each server establishes its own security level for the 
connection, based on its own locally held security 
information. 
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It should not be confused with and does not replace the letter indicating the deferences between the claims 
as filed and as amended. It must be filed on a separate sheet and must be identified as such by a heading, 
preferably by using the words "Statement under Article 1 9(1)." 

It may not contain any disparaging comments on the international search report or the relevance of citations 
contained in that report. Reference to citations, relevant to a given claim, contained in the international search 
report may be made only in connection with an amendment of that claim. 



Consequence If a demand for International preliminary examination has already been filed 

If, at the time of filing any amendments under Article 1 9, a demand for international preliminary examination 
has already been submitted, the applicant must preferably, at the same time of filing the amendments with the 
International Bureau, also file a copy of such amendments with the International Preliminary Examining 
Authority (see Rule 62.2(a), first sentence). 



Consequence with regard to translation of the International application for entry Into the national phase 

The applicant's attention is drawn to the fact that, where upon entry into the national phase, a translation of the 
claims as amended under Article 19 may have to be furnished to the designated/elected Offices, instead of, or 
in addition to, the translation of the claims as filed. 

For further details on the requirements of each designated/elected Office, see Volume II of the PCT Applicant's 
Guide. 
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